Queuing vs Streaming
作者 | Yong Zhang
审校 | Jennifer
编辑 | Irene
What is Apache Pulsar
Pulsar 是下一代的新型消息系统，将批流处理集于一身，并且致力于克服一些现有的消息系统的弱点。Apache Pulsar 是由 Yahoo 开发并开源的企业级消息系统。由 Yahoo 在 2016年开源，并在 2018 年成为 Apache Software Foundation 顶级项目。为了有更好的运行效率、可扩展性和灵活性，Pulsar 从架构上就是分层架构。这样的分层架构相比以往的单体架构更加灵活，可以根据需要来进行配置存储层和处理层，更加容易维护和扩容。
Pulsar Overview
Apache Pulsar 是一个提供多租户并且拥有高性能的消息系统，早期由 Yahoo 进行开发，后由 ASF 进行管理。
Pulsar 有以下特征：
原生支持多集群，并且在集群之间通过地域复制 (geo-replication) 无缝衔接。
端到端之间的低延迟。
百万 topic 无缝扩展。
支持多种客户端比如：Java、Go、C++、Python。
支持独占订阅、共享订阅、故障转移订阅。
用 BookKeeper 保证消息的持久化。
原生支持轻量级微服务计算框架 Pulsar Functions。
基于 Pulsar Functions 的微服务连接器框架 Pulsar IO，方便数据在 Apache Pulsar 的输入输出。
分层存储提供了当数据变为老数据时可以从热存储卸载到类似 S3 或 GCS 的冷存储。
Queuing vs Streaming
Queuing
消息队列没有顺序，并且可以共享，消费者可以从一个点对点的消息队列中接收消息。当有消息发出后，任何消费者都有可能接收到这条消息并进行消费，至于哪个消费者能接收到消息是由消息中间件的实现来决定的。消息队列通常会应用在一些无状态的应用中，这些应用并不关心这些消息的接收顺序，他们只需要将这些收到的消息进行确认或者删除，并且尽可能的去并发处理这些消息。典型的消息系统有 RabbitMQ、RocketMQ。
Streaming
与消息队列正好相反，streaming 是严格要求顺序并且是独占的消息。在流消息这种情况下，通常只有一个消费者消费，并且这条消息是和写入时的顺序一致。流消息通常用于有状态的应用中，这些应用要求消息的顺序与写入时一致，错误的顺序会影响结果的正确性，也会影响对这些消息的处理。队列和流的存在， 在现在的微服务架构和事件驱动架构中举足轻重。
Stream process
流处理是在消息的生产者和消费者中间的处理过程。在消息到达消费者之前，可以自定义输出消息，来达到符合自己要求的消息。通常流处理应用于大数据的处理过程，一些公司的数据都是实时动态生成，采用时间窗口或者其他方式对复杂的流事件进行分析和处理，然后再传递给下一个消费者消费。
Process Guarantees
Process Guarantees 是 Pulsar 中消息接收或处理的保证机制，目前在 Pulsar 中，这种保证大部分是在 Pulsar Functions 中，由于 Pulsar Functions 是一种 Event process， 数据的处理过程对结果会造成影响，所以需要一种机制来保证数据的处理次数。
Pulsar 提供了以下几种状态：
At most once: 指此条消息最多被使用一次。
At least once (default): 指在接收到消息后，这条消息会被至少使用一次；如果不成功，重新拿到消息处理。在 Pulsar Function 处理过程所产生的中间修改会被保存。
Effectively once: 在 Pulsar Functions 只有效处理一次，当一次处理过程出错，中间修改不会被保存。
以上状态大多数在 Pulsar Functions 中使用，在消费者端，Pulsar 会保证 At least once。
更多关于 Pulsar 的技术干货和产品动态，请关注 ApachePulsar 微信公众号。
点击“阅读原文”，进入 Pulsar 官网了解更多。